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Method and Apparatus for E xtending the Range of the Universal Serial Bus 
Protocol as it applies to Asynchronous Transfers 

Field of the Invention 

This invention relates to methods and apparatus for transmitting signals 
5 between devices using Universal Serial Bus ports, and, in particular, to an 

method for allowing communications between devices using such ports over an 
extended range. 

Description of the Related Art 

Universal Serial Bus (USB) is a new technology designed to permit a 
10 wide range of peripherals to be attached to personal computers by the average 
user. Since the technology supports all of the common peripheral devices such 
as keyboards, mice, speakers, modems, joysticks, cameras and many others, it 
will replace the serial and parallel ports in use today. The new Apple iMac 
(Trade Mark), for example, supports only USB ports. In addition, almost every 
15 personal computer (PC) manufactured since 1997 has been equipped with USB 
ports. 

USB was created by an alliance of seven of the largest companies in the 
computer and communication markets. Those companies were Intel, Compaq, 
Microsoft, NorTel, NEC, Digital and IBM. The specifications defining USB (e.g. 

20 Intel et al., Universal Serial Bus Specification, Revision 1.0, January 1996; - 
hereinafter referred to as the "USB Specification") are non-proprietary and are 
managed by an open industry organization known as the USB Forum. The USB 
Specification establishes a number of criteria which must be met in order to 
comply to USB standards. 

25 For example, it is a current requirement of the USB Specification that a 

single USB domain shall support up to 127 devices operating over a shared 
medium providing a maximum bandwidth of 12 Mbps. 
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Further, the USB Specification limits the distance that a device can be 
separated from its host PC to 5 meters. By using a series of USB Hubs - 
devices that are intended to support increased populations rather than 
increased distances - this distance limitation can be increased, in theory, to 30 
5 meters. This multiple hub solution is both expensive and clumsy. For example, 
to support a single device at a range of 30 meters the consumer must purchase 
five hubs at a current cost of about $50 US each. In addition, at least two of 
these hubs must be provided with electrical power. Since the individual cables 
between hubs are limited to 5 meters each, it is also likely that some of the hubs 

10 would have to be positioned in very inconvenient and insecure locations. 

There is therefore a need for methods and apparatus to allow USB 
devices to be positioned at greater distances from the host PC. For example, an 
uninterrupted distance of at least 100 meters is required for compatibility with 
the standards governing the cabling of commercial buildings (see, for example, 

15 TIA/EIA-568-A, Commercial Building Telecommunications Cabling Standard, 
Telecommunications industry Association, October 1995). Meeting this standard 
must be accomplished without the need for intermediate repeaters since 
distribution cabling is not normally accessible between its end-points at, for 
example, the Telecommunications Closet and the Work Area. Furthermore, 

20 even if the cable were to be accessible, the cabling standard does not allow 
active devices to be inserted other than at the end-points. 

Providing for an extended range capability would also create new 
applications for USB devices as well as facilitating existing ones. For example, a 
simple residential or SOHO (small office, home office) surveillance system could 

25 be constructed by connecting consumer quality cameras to a central PC. An 
overhead mounted monitor could be controlled by a remote keyboard or mouse. 
A door-phone entrance system could be monitored from any office in a 
commercial building. 

Currently, however, the USB Specifications do not permit the use of 

30 extended ranges. For example, it is a further requirement of the USB 

Specification that the access of each device to the shared communications bus 
is controlled by a single Host Controller. It is also specified that when the Host 
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Controller instructs a particular device to place its information onto the shared 
bus, the requested information must be received by the Host Controller within 
sixteen (16) bit-times of said Host Controller issuing said instruction. In practise, 
this ensures that the USB Specification provides for a high efficiency of 
5 bandwidth utilization by limiting the period during which no information is being 
transmitted. However, these requirements also limit the physical range of USB 
devices since one bit-time is equivalent to the time taken for an electronic signal 
to traverse approximately 17 meters of copper cable. 

Further, although the USB device must respond to a request from the 

10 Host Controller within 16 bit-times, 7,5 bit-times is allocated for delay within a 
USB device and its associated 5 meter cable. This allocation retains only 8.5 
bit-times for additional cable delay. The time represented by 8.5 bit-times is 
equivalent to the delay incurred by electronic signals in traversing approximately 
144 meters of cable. However, this cable length is insufficient to satisfy the 

15 round-trip cable length of 200 meters required by the premise cabling 
specification. 

Thus, it is not currently possible to provide USB devices which are 
separated over an extended distance. 

However, it is a further feature of the USB Specification that the USB 
20 Specification (or protocol) segregates access to the shared bus into discrete 
units known as frames. Each frame is designed to last for a period of 1 ms. 

In our co-pending Canadian patent application No. 2262334, filed 
February 19, 1999, a method and device are described, that provides for use of 
a USB system with extended range, when the device is used for isochronous 
25 data transfer. 

Isochronous data transfer is characterised as being a data transfer 
wherein data flows essentially continuously, and at a steady rate, in close timing 
with the ability of the receiving mechanism to receive and use the incoming 
data. This type of data transfer is distinguished from asynchronous data 
30 transfer, which pertains to processes that proceed independently of each other 
until a dependent process has to "interrupt" the other process, and synchronous, 
which pertains to processes in which one process has to wait on the completion 
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of an event in another process before continuing. It should be noted that it is an 
aspect of isochronous transfers that timely delivery of information is ensured at 
the expense of potential transient losses in the data stream. In particular, there 
is no attempt to retransmit any data that may have been lost in previous 
5 transmissions. For example, with an isochronous video signal, loss of one frame 
of information is generally not significant, and there is no interest in retrieving 
the lost frame. Instead, the host controller is typically more concerned with 
receiving the current frame. Accordingly, isochronous data transfer is said to be 
time-relevant data transfer system. 
10 In contrast, asynchronous data transfer is not time-relevant. Instead, a 

correct response to any request is required. 

The current invention therefore uses the fundamental characteristics of 
asynchronous data, and more generally any non-time-relevant data 
transmission, and the existence of regular protocol frames in order to provide 
15 methods and apparatus to enable data transmission over extended distances. 

Accordingly, while USB technology has proven to be useful, it would still 
be desirable to provide improvements to the technology by providing a method 
and apparatus for enabling data transmission equipment, and in particular, data 
transmission equipment utilizing the USB Specification, to be used over an 
20 extended range for asynchronous data transfers. 

Therefore, it is an object of the present invention to provide methods and 
apparatus to enable devices, hubs and controllers and other devices that 
conform to the USB Specification to communicate over distances greater than 
that currently permitted under said USB Specification. 
25 It is a further object of the present invention that such extended range be 

achieved without the need for intermediate hubs, repeaters or other methods of 
electronic signal regeneration. 

It is a further object of the present invention that no hardware or software 
changes need be made to the existing devices, hubs and controllers supported 
30 by the system, and in particular, a system operating under the USB 

Specification when utilizing asynchronous data transfers. The invention, 
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thereby, may be incorporated into networks composed of both conventional 
range and extended range devices. 

It is a further object of the present invention that the apparatus be very 
cost effective, consistent with the broadest population of devices targeted by the 
5 USB industry. 

These and other objects of the invention, which will become apparent 
herein, are attained by the present invention as described hereinbelow. 



Summary of the Invention 

Accordingly, the present invention provides a method for transmitting a 
10 non-time-relevant data stream, and in particular an asynchronous data stream, 
between a host controller and a peripheral device over an extended distance; 
said method comprising: 

a) feeding a first original, outgoing digital signal from a host controller to a 
local expander unit; 

15 b) optionally converting said outgoing digital signals into a converted 
outgoing signal having a format suitable for transmission over extended 
distances; 

c) transmitting either said outgoing digital signal or said converted outgoing 
signal, as an outgoing transmission signal, over a signal distribution system; 
20 d) receiving said outgoing transmission signal at a remote expander unit; 

e) optionally converting said outgoing transmission signal to said first 
original outgoing digital signal; 

f) delivering said first original outgoing digital signal from said remote 
expander to at least one peripheral device; 

25 g) receiving, at said remote expander, a reply digital signal from said 
peripheral device; 

h) optionally converting said reply digital signal into a converted reply signal 
having a format suitable for transmission over extended distances; 
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i) transmitting said reply digital signal or said converted reply signal as a 
reply transmission signal over said signal distribution system; 
j) receiving said reply transmission signal at said local expander; 
k) optionally converting said reply transmission signal to said original reply 
5 digital signal; 

I) storing said reply digital signal as a stored reply digital signal until the 
receipt of a subsequent original, outgoing digital signal from said host controller, 
which subsequent signal is the same as, or similar to, said first original outgoing 
digital signal; and 

10 m) forwarding said stored reply digital signal to said host controller in 
response to said subsequent original outgoing digital signal. 

For the purposes of the present specification, the term "non-time-relevant 
data* is meant to relate to data streams such as asynchronous data streams 
wherein loss of a frame from a previous transmission is not acceptable, and that 
15 current, correct transfer of information is required. 

In a preferred embodiment, all digital signals conform to the USB 
Specification (other than for the distance between devices), and, preferably all 
digital signals represent asynchronous data. Further, in a preferred 
embodiment, the extended distance exceeds 5 meters, more preferably, 
20 exceeds 30 meters, and still more preferably, exceeds 100 meters. In particular, 
the distance between the local expander and the remote expander exceeds 5 
meters, more preferably, exceeds 30 meters, and still more preferably, exceeds 
100 meters. 

While a number of different signal distribution systems might be used, 
25 preferably, the signal distribution system utilizes unshielded twisted pair (UTP) 
wiring (or cabling). 

In a further preferred embodiment, the present invention provides a 
method for transmission of asynchronous data according to the USB 
Specification wherein asynchronous data is transmitted from a peripheral device 
30 and is received by a host controller, said method comprising: 
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a) receiving, at a local expander, an original request for asynchronous data 
from a host controller; 

b) forwarding said original request for asynchronous data from said local 
expander to a remote expander over a signal distribution system; 

5 c) receiving, at a remote expander, said forwarded original request for 
asynchronous data; 

d) delivering said forwarded original request for asynchronous data to at 
least one peripheral device; 

e) receiving, at said remote expander, the requested asynchronous data 
10 from said peripheral device; 

0 forwarding said requested asynchronous data from said remote expander 
to said local expander over said signal distribution system; 
g) storing, in a packet buffer at said local expander, said requested 
asynchronous data; 

15 h) receiving, at said local expander, a subsequent request for asynchronous 
data from said host controller; and 

i) forwarding said subsequent request for asynchronous data from said 
local expander to a remote expander over a signal distribution system; 

ii) delivering said forwarded subsequent request for asynchronous data to 
20 at least one peripheral device; 

iii) receiving, at said remote expander, the requested asynchronous data 
from said peripheral device; 

i) additionally receiving, at said local expander, said subsequent request for 
asynchronous data from said host controller as in step (h); and 
25 i) retrieving the stored asynchronous data from said packet buffer; 

ii) delivering said retrieved asynchronous data to said host controller; 
j) receiving, at said local expander, an outgoing acknowledgement signal 
from said host controller; 

k) optionally converting said outgoing acknowledgement signal into a 
30 converted acknowledgement signal having a format suitable for transmission 
over extended distances; 
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I) transmitting either said outgoing acknowledgement signal or said 
converted acknowledgement signal, as an acknowledgement transmission 
signal, over a signal distribution system; 

m) receiving, at a remote expander unit, said acknowledgement transmission 
5 signal; 

n) optionally converting said acknowledgement transmission signal to said 
outgoing acknowledgement signal; and 

o) delivering said outgoing acknowledgement signal from said remote 
expander to at least one peripheral device. 



10 In a preferred feature, the method also provides the following additional 

steps after step (b) described hereinabove, namely: 

i) Determining whether said local expander already possesses said 
requested asynchronous data; 

ii) Generating a negative acknowledgement packet if no such 
15 requested asynchronous data is present; and 

iii) Delivering said negative acknowledgement packet to said host 
controller. 



In an even more preferred embodiment, the present invention also 
provides a method as described hereinabove with respect to the present 
20 invention, wherein said method provides a method for transmission of 

asynchronous data according to the USB Specification wherein asynchronous 
data is transmitted from a host controller and is received by a peripheral device, 
said method comprising: 

a) receiving, at a local expander, an original notification of asynchronous 
25 data from a host controller; 

b) forwarding said original notification of asynchronous data from said local 
expander to a remote expander over a signal distribution system; 

c) receiving, at a remote expander, said forwarded original notification of 
asynchronous data; 
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d) receiving, at a local expander, an original asynchronous data packet from 
a host controller; 

e) forwarding said original asynchronous data packet from said local 
expander to a remote expander over a signal distribution system; 

5 f) receiving, at a remote expander, said forwarded original asynchronous 
data packet; 

g) delivering said forwarded original asynchronous data packet to at least 
one peripheral device; 

h) receiving, at said remote expander, an inbound acknowledgement packet 
10 from said peripheral device; 

i) forwarding said inbound acknowledgement packet from said remote 
expander to said local expander over said signal distribution system; 

j) storing, in a packet buffer at said local expander, said inbound 
acknowledgement packet; 
15 k) receiving, at said local expander, a subsequent notification of 
asynchronous data from said host controller; 

I) receiving, at said local expander, a subsequent asynchronous data 
packet from said host controller; and 

i) retrieving said stored inbound acknowledgement packet from said 
20 packet buffer; and 

ii) delivering said retrieved inbound acknowledgement packet to said 
host controller. 

In a further preferment, the method described hereinabove additionally 
comprises the following steps, namely: 
25 j) Determining whether said local expander already possesses said 

inbound acknowledgement packet; 

ii) Generating a negative acknowledgement packet if no such 
inbound acknowledgement packet is present; and 

Hi) Delivering said negative acknowledgement packet to said host 
30 controller. 

In systems wherein a guard time is imposed after a data packet is 
transmitted (in order to prevent premature transmission of another packet), a 



CA 02269961 1999-04-26 

SL2017 A 



-10- 

preferred embodiment of the present invention also provides a method as 
described hereinabove additionally comprising the following stages: 

a) Receiving, at a remote expander, an outbound data packet, 

b) Determining, at a remote expander, the transfer type of said outbound 
S data packet, 

c) Forwarding said outbound data packet from said remote expander to a 
USB device, 

d) Setting the value of a transmission guard timer to a value that is that is 
dependent upon said determined transfer type; and 

10 e) Inhibiting further outbound transmissions until said guard timer has 
expired. 



As with the prior art, the method of the present invention can be used in a 
systems wherein said host controller is a PC, and said peripheral device is a 
camera, a mouse, a keyboard, a monitor or a speaker or speakers. 



15 In another aspect, the present invention also provides an apparatus for 

transmission of a digital signal over an extended distance comprising: 

a) a local expander comprising means for receiving a request for a 
non-time-relevant data signal, preferably wherein said non-time-relevant data 
signal is a digital signal which conforms to the USB Specification, and wherein 

20 said non-time-relevant signal represents asynchronous data , from a host 
controller which host controller is connected to said local expander; 

b) means in said local expander for generating an outgoing transmission 
signal; 

c) means in said local expander for sending said outgoing transmission 
25 signal to a remote expander, which signals are sent over a signal distribution 

system; 

d) a remote expander comprising means for receiving said outgoing 
transmission signal; 

e) means in said remote expander for generating a digital signal from said 
30 outgoing transmission signal; 
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f) means in said remote expander for forwarding said digital signal to at 
least one peripheral device, which peripheral device is connected to said remote 
expander; 

g) means in said remote expander for receiving inbound digital signals from 
5 said peripheral devices; 

h) means in said remote expander for converting said inbound digital 
signals to an inbound transmission signal; 

i) means in said remote expander for sending said inbound transmission 
signal to said local expander, which signals are sent over said signal distribution 

10 system; 

j) means in said local expander for receiving said inbound transmission 
signal; 

k) means in said local expander for generating a digital signal from said 
inbound transmission; and 
IS I) means in said remote expander for forwarding said digital signal to said 
host controller. 

In a preferred embodiment, the present invention also provides an 
apparatus wherein said local expander additionally comprises: 
a) means for storing said inbound signal as a stored inbound signal; 
20 b) means for analysing said digital signal from said host controller to 
recognize a subsequent request for transmission of said non time-relevant 
digital signal; and 

c) means for sending said stored inbound signal to said host controller in 
response to said subsequent request. 



25 
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Description of the Preferred Embodiments 

Although a number of signal distribution systems may be used, as 
described hereinabove, preferably the signals are transmitted over a signal 
distribution system which utilizes Unshielded Twisted Pair (UTP) copper wire. 
5 Using this method of device connection provides a low cost, effective means for 
data transmission. However, in another embodiment of the system, signals can 
be transmitted over coaxial cable. 

While the methods and apparatus of the present invention have general 
utility in a variety of applications, it is of primary importance that the data 

10 transmission methods and apparatus of the present invention allow for 

compliance with the USB Specifications. Preferably, the original signal from the 
host controller is a request for data from a peripheral device. Additionally, 
preferably the data requested is asynchronous data from peripheral devices 
such as cameras, keyboards, mice, monitors, speakers, and the like. 

15 In particular, during operations utilizing the methods and apparatus of the 

present invention in applications involving extended range transmissions, it is 
preferred that the apparatus be preferably capable of recognizing asynchronous 
transfers, when they are received. The data contained within the asynchronous 
transfer is then stored within the system for a period of time. Accordingly, the 

20 data that is received during a particular frame may be stored and then 

transmitted in a following frame. Additionally, a further preferred embodiment of 
the present invention is that asynchronous transfers originating from a plurality 
of sources may be stored, and retransmitted. 

In the operation of a preferred embodiment of the current invention, a 

25 host controller (which preferably is a PC) may issue a request to a device for the 
transfer of asynchronous data. The request is received by the apparatus of the 
present invention, and retransmitted to the target device. When the requested 
asynchronous transfer response is received by the apparatus from the target 
device, the asynchronous data is stored within the internal memory of the 

30 apparatus. During a subsequent frame, the host controller will again issue a 
request to the target device for the transfer of asynchronous data. The 



•CA 02269961 1999-04-26 



-13- 

apparatus will again retransmit this request to the target device. In addition, 
however, the apparatus recognizes that it currently has asynchronous data from 
the target device stored in its internal memory. The apparatus sends this data to 
the host controller within the 16 bit-time margin relevant to the current request 
5 within the current frame. In this manner, the apparatus uses data collected in a 
previous frame to satisfy the response time requirement of a current frame. 

By utilizing the method and apparatus of the present invention, it is 
possible to have transfer of non-time-relevant data, and asynchronous data in 
particular, over extended distances, and in particular, over distances greater 
10 than specified in the USB Specification. 



Brief Description of the Drawings 

The invention, and various aspects thereof, will be described by 
reference to the attached drawings wherein: 

Figure 1 is a PC equipped with a conventional USB Hub and USB 
15 Devices. 

Figure 2 is a PC equipped with an Extended Range Hub and USB 
Devices according to the present invention. 

Figure 3 is a schematic drawing of an embodiment of the invention 
designed to operate over UTP. 
20 Figure 4 is a timing diagram showing asynchronous transfers according 

to the USB protocol. 

Figure 5 is a timing diagram showing asynchronous transfers according 
to the current invention. 

Figure 6 is a schematic drawing of an embodiment of a Local Expander 
25 according to the invention. 

Figure 7 is a schematic drawing of an embodiment of a Remote Expander 
according to the invention. 
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Figure 8 is a sequence diagram showing an asynchronous input transfer 
according to the invention. 

Figure 9 is a sequence diagram showing an alternative asynchronous 
input transfer according to the invention 
5 Figure 10 is a sequence diagram showing an asynchronous output 

transfer according to the invention. 

Figure 1 1 is a sequence diagram showing an alternative asynchronous 
output transfer according to the invention. 

Figure 12 is a logic diagram of a LEX controller according to the 
10 invention. 

Figure 13 is a logic diagram of an enhanced LEX controller according to 
the invention. 

Figure 14 is a logic diagram of a REX controller according to the 
invention. 

15 Figure 15 is a schematic drawing of a REX Controller according to the 

invention. 

Figure 16 is a sequence diagram showing a link layer packet output 
according to the invention. 

Figure 17 is a sequence diagram showing a link layer packet input 
20 according to the invention. 

Figure 18 is a logic diagram of a Link Controller according to the 
invention. 

In the drawings, Figure 1 shows a PC (1) equipped with two conventional 
USB Hubs (2a & 2b), and four standard USB Devices (3a, 3b, 3c & 3d). The 
25 length of cable between hubs (2a) and (2b) cannot exceed 5 meters according 
to the current USB specification. 

Figure 2 shows a PC (1 ) equipped with an apparatus according to the 
present invention, which is termed as an "Extended Range Hub" (7) and four 
standard USB Devices (3a, 3b, 3c & 3d). The Extended Range Hub is 
30 composed of two separate units, a "Local Expander" (4) and a "Remote 
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Expander" (5) connected by cable (6). In one embodiment of the invention, units 
(4) and (5) can be separated by up to 200 meters of Category 5 UTP cable (6). 

Figure 3 illustrates an embodiment of the invention designed to operate 
over UTP. In this embodiment, the functions normally provided by a USB Hub 
5 are provided by two separate units connected by a length of Unshielded 

Twisted Pair (UTP) copper wiring (6a). A Host PC may be connected to the first 
unit (4), referred to as Local Expander (LEX). The second unit (5) is referred to 
herein as Remote Expander (REX). The Remote Expander (5) may be 
connected to a plurality of USB devices. In this embodiment said plurality is 

10 chosen to be four, but it will be clear to those skilled in the art that other choices 
may be made within the scope of the invention. 

Operation over extended distances is achieved by placing said LEX unit 
(4) close to said Host PC, placing said REX unit (5) close to said plurality of 
USB devices, and connecting LEX unit (4) and REX unit (5) by the required 

15 extended length of UTP cabling (6a). 

Figure 4 provides a timing diagram showing asynchronous transfers 
according to the USB protocol. The diagram is constructed from the point of 
view of a USB Host Controller, normally included on a PC motherboard (Host 
PC). The USB protocol divides time allocation on the shared bus into regular 

20 Frames, each of 1 ms in duration. The start of each frame is identified on the 
diagram as F1, F2, F3 & F4. 

When a Host Controller is engaged upon an asynchronous transfer with a 
device, the Host Controller issues requests for data transfer to said device on 
an as needed basis. These requests are identified in Figure 4 as packets R1 & 

25 R2 (10 & 12). Under the USB protocol, a USB device must respond to said 

request within 16 bit-times. The responses are shown in the diagram as packets 
A1 & A2 (1 1 & 13). It is commonly expected that transfer A1 (1 1) will be 
delivered in response to request R1 (10), transfer A2 (13) will be delivered in 
response to request R2 (12), and so on until the requests are terminated. 

30 Figure 5 provides a timing diagram showing asynchronous transfers 

according to the present invention. The diagram shows the progression of 
packets through the various subsystems comprising the invention. Timelines are 
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presented for the Host PC (1), Local Expander (4) and Remote Expander (5) 
subsystems as shown in Figure 2. 

An asynchronous transfer is initiated from a Host PC (1 ) by emitting a 
request for input data R1 (20) to a particular USB address and end-point. Said 
5 request R1 (20) is received by the LEX (4) and retransmitted as R1 (24) over the 
external cabling to the REX (5). Said retransmitted packet R1 (24) is received by 
the REX (5) and forwarded as R1 (29) to the target device (i.e. one of items 3a, 
3b, 3c or 3d). 

The target device generates an input data packet A1 (30). According to 

10 the USB protocol, a device without an integrated cable must generate a 

response within 6.5 bit-times of the end of the corresponding request. Said input 
data packet A1 (30) is received by the REX subsystem (5) and retransmitted as 
A1 (25) over the external wiring to the LEX (4). Said retransmitted response A1 
(25) is not immediately forwarded to the Host PC (1 ), but is stored within the 

15 memory of the LEX subsystem (4). 

The Host PC (1 ) notices that it did not receive a response to its input data 
request R1 (20), and retries the transaction by generating a new request R2 
(21) to the same USB address and end-point. Upon receiving request R2 (26), 
the LEX subsystem (4) retrieves response A1 (25) from its memory buffers and 

20 forwards it to the Host PC as response A1 (27). Said response (27) is received 
by the Host as response A1 (22). 

Said second request R2 (21) is repeated as R2 (26) through the LEX and 
forwarded as R2 (31 ) to the device. The target device generates a second 
response A2 (32) which is simply absorbed by the REX subsystem (5). When 

25 the Host receives said response A1 (22), it generates acknowledgement K1 (23) 
which it transmits to the LEX subsystem (4). Said acknowledgement K1 (23) is 
received by the LEX as acknowledgement K1 (28) and forwarded to the REX 
where it appears as acknowledgement K1 (33). Said acknowledgement K1 (33) 
is again forwarded to the USB device to complete the protocol sequence. 

30 Figure 6 illustrates one embodiment of a Local Expander (4) according to 

the invention. Said embodiment comprises four major blocks. The USB Interface 
(50) enables a Host PC to be connected to the unit using standard USB cabling. 
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Said USB Interface receives signals in USB format from said Host PC and 
delivers USB packets to the LEX Controller (51). Said LEX Controller 
determines what response is necessary to the received packet and generates 
the appropriate USB packets. If said LEX Controller requires information to be 
5 stored prior to transmission, then said information is stored in RAM (53). 

Information that must be sent to the Remote Expander (5) is forwarded to 
the UTP interface (52) wherein the information is converted into digital signals 
suitable for propagation over copper cabling. 

In the reverse direction, digital signals originating from the Remote 
10 Expander (5) are received by UTP interface (52) and forwarded to LEX 

Controller (51). Said LEX Controller saves any necessary information in RAM 
(53) and generates the required responses. Information that must be sent to the 
Host PC is transferred to the USB Interface (50), from where it may be 
forwarded to said Host PC using standard USB hardware and protocols. 
15 Figure 7 illustrates an embodiment of a Remote Expander (5) according 

to the invention. Said embodiment comprises a UTP Interface (60), a plurality of 
USB Interfaces (63)-(66), a REX Controller (61) and a RAM (62). Operation of 
the REX (5) is similar to that of the LEX (4). 

Figure 8 provides a sequence diagram showing an asynchronous input 
20 transfer according to the invention. The format used in the diagram is 

attributable to Jacobson et al. (Ivar Jacobson, Magnus Christerson, Patrick 
Jonsson and Gunnar Overgaard, Object-Oriented Software Engineering: A Use 
Case Driven Approach, Addison-Wesley, 1992.) 

In Frame 1 , the control logic (130) within the Host PC generates a 
25 request for input data, addressed to a particular USB function. Said request is 
transmitted to the LEX subsystem as an "In Addr" packet. The control logic (131) 
within the LEX subsystem forwards the In Addr packet to the REX subsystem. 
The control logic (132) within the REX subsystem forwards the In Addr packet to 
the Device. The control logic (133) within the device assembles the requested 
30 asynchronous data and transmits it as a "Data Pay load" packet to the REX 

subsystem. The control logic (132) within the REX subsystem forwards the Data 
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Payload packet to the LEX subsystem. The control logic (131) in the LEX 
subsystem stores the Data Payload packet in its buffer memory. 

In Frame 2, the control logic (134) within the Host PC recognizes that it 
has not received a response to its previous request for input data. Said control 
5 logic automatically retries the transaction by generating a further request 
addressed to the same USB function as in Frame 1 . Said further request is 
transmitted to the LEX subsystem as a second In Addr packet. On receipt of the 
second In Addr packet, the control logic (135) within the LEX subsystem 
recognizes that it has a Data Payload packet stored in memory from the same 
10 function identified by the further In Addr packet. Said control logic retrieves said 
stored packet from memory and transmits same to the Host PC. Said control 
logic (135) also forwards the new In Addr packet to the REX subsystem. The 
control logic (136) within the REX subsystem forwards the In Addr packet to the 
Device. 

15 The control logic (137) within the device recognizes that it did not receive 

an acknowledgement to its previous transmission and assumes that this new 
request is in fact a second request for the original information. The device 
thereby assembles the requested asynchronous data and transmits it as a Data 
Payload packet to the REX subsystem. The control logic (136) within the REX 

20 subsystem recognizes that said Data Payload packet is merely a repetition of 
the previous transmission and absorbs said packet. 

When the control logic (134) of the Host receives the requested Data 
Payload packet from the LEX, said control logic generates an Ack packet to 
acknowledge a successful transmission. Said Ack packet is received by control 

25 logic (135) within the LEX and forwarded to the REX. Said forwarded Ack packet 
is received by control logic (136) within the REX and further forwarded to the 
device. The transmission of the Ack packet from the REX to the device is 
synchronised by control logic (136) to occur within the required response period 
following the end of transmission of the repeated Data Payload packet from the 

30 device. 

Figure 9 provides a sequence diagram showing an alternative 
asynchronous input transfer according to the invention. This method differs from 
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that described in Figure 8 in the manner in which the first request for an 
asynchronous input transfer is handled by the LEX. 

In Frame 1, the control logic (130) within the Host PC generates a 
request for input data, addressed to a particular USB function. Said request is 
5 transmitted to the LEX subsystem as an In Addr packet. The control logic (131 ) 
within the LEX subsystem forwards the In Addr packet to the REX subsystem as 
described in Figure 8. 

At this point in the sequence, an additional step is introduced. Said 
control logic (131) within the LEX subsystem generates a synthetic negative 
10 acknowledgement packet and transmits it as a Nak packet to the Host PC. Said 
Nak packet warns the Host that it will not receive a response to its request and 
enables said Host to progress to the next transaction. The remainder of the 
protocol handling continues as described in Figure 8. 

Figure 10 provides a sequence diagram showing an asynchronous output 
15 transfer according to the invention. 

In Frame 1, the control logic (140) within the Host PC generates a 
notification of output data, addressed to a particular USB function. Said 
notification is transmitted to the LEX subsystem as an Out Addr packet. The 
control logic (141 ) within the LEX subsystem forwards said Out Addr packet to 
20 the REX subsystem. The control logic (142) within the REX subsystem forwards 
said Out Addr packet to the Device. The information is received by the control 
logic (143) within the device. 

The control logic (140) within the Host PC assembles the notified 
asynchronous data and transmits same as a Data Payload packet to the LEX 
25 subsystem. The control logic (141 ) within the LEX subsystem forwards the Data 
Payload packet to the REX subsystem. The control logic (142) in the LEX 
subsystem further forwards the Data Payload packet to the device. The 
information is received by the control logic (143) within the device. 

Upon successful receipt of said Data Payload packet by the device, the 
30 control logic (143) within the device generates an acknowledgement packet 
which is transmitted as an Ack packet to the REX. Said Ack packet is forwarded 
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by control logic (142) within the REX to the LEX subsystem where its receipt is 
recorded by control logic (141). 

In Frame 2, the control logic (144) within the Host PC recognizes that it 
has not received an acknowledgement of its previous transmission and 
5 generates a new Out Addr packet addressed to same end point as in Frame 1 . 
The same control logic (144) also generates a new Data Pay load packet which it 
transmits to the LEX. Upon receipt of the Data Payload packet by the LEX, the 
control logic (145) recognizes that it has already received positive 
acknowledgement of this transaction and generates an Ack packet which it 

10 sends to the Host. 

Figure 1 1 provides a sequence diagram showing an enhanced 
asynchronous output transfer according to the invention. This method differs 
from that described in Figure 10 in the manner in which the first request for an 
asynchronous output transfer is handled by the LEX. 

15 In Frame 1 , the control logic (140) within the Host PC generates a 

notification of output data, addressed to a particular USB function. Said request 
is transmitted to the LEX subsystem as an Out Addr packet. The control logic 
(141 ) within the LEX subsystem forwards the Out Addr packet to the REX 
subsystem as in Figure 10. 

20 Also in Frame 1, the control logic (140) within the Host PC generates an 

output data packet, destined for said particular USB function. Said output data 
packet is transmitted to the LEX subsystem as an Data Payload packet. The 
control logic (141) within the LEX subsystem forwards the Data Payload packet 
to the REX subsystem as in Figure 10. 

25 At this point in the sequence, an additional step is introduced. Said 

control logic (141) within the LEX subsystem generates a synthetic negative 
acknowledgement packet and transmits it as a Nak packet to the Host PC. Said 
Nak packet warns the Host that it will not receive a response to its transmission 
and enables said Host to progress to the next transaction. The remainder of the 

30 protocol handling continues as described in Figure 10. 

Figure 12 provides an algorithm for implementing asynchronous transfers 
at the Local Expander (4). In the embodiment of the invention described in 
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Figure 6, said algorithm is implemented in hardware by LEX Controller (51). (It 
will be apparent to those skilled in the art that this implementation is not unique 
and that other mechanisms for implementing said algorithm are possible.) In the 
following description, the inbound direction refers to packets travelling from a 
5 peripheral device and towards a host controller; the outbound direction refers to 
packets travelling from a host controller and towards a peripheral device. 

According to the invention, the algorithm of Figure 12 is required to 
implement the processing functions represented by processing blocks (131) & 
(135) of Figure 8. and processing blocks (141) & (145) of Figure 10. 
10 On initial power-up and after a reset, the system enters Idle state (300) 

where it waits for a message (USB packet) to be received. When a packet is 
received, the Packet Identifier (PID) field within the packet is examined to 
determine what type of packet has been received and what action is required to 
process said packet. 

15 If the received packet (301 ) is of type IN, the system retransmits (302) 

said IN packet to the REX unit. The systems then examines its buffer memory 

(303) to determine whether an inbound DATA packet from the same address as 
the IN packet is available. If said DATA packet is available, then it is retrieved 

(304) from buffer memory and transmitted (305) to the Host. The system returns 
20 to the Idle state (300). 

If the received packet (306) is of type DATA and is travelling in the 
inbound direction, the system saves (307) said data packet in its buffer memory 
and returns to the Idle state (300). 

If the received packet (308) is of type ACK and is travelling in the 
25 outbound direction, the system retransmits (309) said ACK packet and returns to 
the Idle state (300). 

If the received packet (310) is of type OUT, the system tests (31 1) 
whether the OUT pending flag for the address is set. If said flag is set, the 
system resets said flag and returns to the Idle state (300). If said flag is not set, 
30 the system sets (312) said flag and retransmits (313) said received OUT packet 
before returning to the Idle state (300). 
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If the received packet (31 5) is of type DATA and is travelling in the 
outbound direction, the system tests (316) whether the DATA pending flag for 
the address is set. If said flag is not set, the system sets (323) said flag and 
retransmits (324) said received DATA packet before returning to the Idle state 
5 (300). If said DATA pending flag is set, the system resets (317) said DATA 
pending flag and tests (318) whether an ACK packet for the address has been 
stored in buffer memory. If said Ack packet is present in memory, the system 
retrieves (319) said packet from memory and transmits (320) said packet to the 
Host. The system returns to the Idle state (300). 

10 If the received packet (321 ) is of type ACK and is travelling in the 

inbound direction, the system saves (322) said ACK packet in buffer memory 
and returns to the Idle state (300). 

Figure 13 provides an enhanced algorithm for implementing 
asynchronous transfers at the Local Expander according to the invention 

15 described in Figure 6. This algorithm is identical to that described in Figure 12, 
other than in the manner in which the LEX informs the Host that a response to 
its commands is not available. This situation occurs when the Host initiates a 
data transfer sequence as described in Figures 9 and 11. 

Additional step (331) occurs when the system receives an IN packet but 

20 does not have the requested data stored in buffer memory. The system 

transmits (331) a negative acknowledgement packet to the Host before returning 
to the Idle state (300). 

Additional step (332) occurs when the system receives an DATA packet 
travelling in the outbound direction but the DATA pending flag has not been set. 

25 The system transmits (332) a negative acknowledgement packet to the Host 
before returning to the Idle state (300). 

Figure 14 provides an algorithm for implementing asynchronous transfers 
at the Remote Expander. In the embodiment of the invention described in Figure 
7, said algorithm is implemented in hardware by REX Controller (61). (It will be 

30 apparent to those skilled in the art that this implementation is not unique and 
that other mechanisms for implementing said algorithm are possible.) In the 
following description, the inbound direction refers to packets travelling from a 
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peripheral device and towards a host controller; the outbound direction refers to 
packets travelling from a host controller and towards a peripheral device. 

According to the invention, the algorithm of Figure 14 is required to 
implement the processing functions represented by the processing blocks (132) 
5 & (136) of Figure 8, and the processing block (142) of Figure 10. 

On initial power-up and after a reset, the system enters Idle state (340) 
where it waits for a message (USB packet) to be received. When a packet is 
received, the Packet Identifier (PID) field within the packet is examined to 
determine what type of packet has been received and what action is required to 
10 process said packet. 

If the received packet (341) is of type IN, the system retransmits (342) 
said IN packet and returns to the Idle state (340). 

If the received packet (343) is of type DATA and is travelling in the 
inbound direction, the system tests (344) whether the data pending flag for the 
15 address has been set. If said flag is set, the system resets (345) said flag and 
returns to the Idle state (340). If said data pending flag is not set, the system 
sets (346) said flag and retransmits (347) said received DATA packet to the LEX 
before returning to the Idle state (340). 

If the received packet (348) is of type ACK and is travelling in the 
20 outbound direction, the system retransmits (349) said ACK packet and returns to 
the Idle state (300). 

If the received packet (350) is of type OUT, the system retransmits (351) 
said OUT packet and returns to the Idle state (340). 

If the received packet (352) is of type DATA and is travelling in the 
25 outbound direction, the system retransmits (353) said DATA packet and returns 
to the Idle state (340). 

If the received packet (354) is of type ACK and is travelling in the 
inbound direction, the system retransmits (355) said ACK packet and returns to 
the Idle state (340). 

30 Figure 1 5 illustrates an embodiment of a REX Controller (61 ) according 

to the embodiment of the invention shown in Figure 7. In this embodiment, the 
control functions of the REX are separated into two distinct components, the 
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Network Controller (403) and the Link Controller (401). First In First Out (FIFO) 
buffers (400) & (402) are used to hold individual packets as they are sent to and 
received from the USB Interface (63). 

The separation of functions into discrete controllers (403) and (401 ) 
5 enables the operation of the system to be described more simply. The Network 
Controller (403) performs the network layer functions as described in Figure 14, 
while the Link Controller (401) performs the link layer functions associated with 
transmitting and receiving individual packets. 

The following signals are provided between the components of Figure 15. 
10 The Network Controller (403) generates signal ISO to indicate that the packet it 
has placed in TX FIFO (402) is related to an isochronous transmission and an 
acknowledgement is not expected. 

TX FIFO (402) generates signal TXRDY to indicate that it contains a 
complete packet ready to be sent. TX FIFO (402) also generates signal TXOVR 
IS to indicate that it has completed sending a packet to USB Interface (63). 

RX FIFO (400) generates signal SOP to indicate that it has started to receive a 
packet from USB Interface (63). RX FIFO (400) also generates signal EOP to 
indicate that it has completed receiving a packet from USB Interface (63). The 
Link Controller (401 ) generates signal TXENB to inform TX FIFO (402) that TX 
20 FIFO is cleared to send its information to USB Interface (63). 

Figure 16 provides a sequence diagram showing a link layer packet 
output. In this drawing, control logic (410) is implemented by Network Controller 
(403), control logic (411) is implemented by Link Controller (401, control logic 
(412) is implemented by TX FIFO (402) and control logic (413) is implemented 
25 by USB Interface (63). 

A link layer output sequence is started when the Network Controller (403) 
copies a data packet to the TX FIFO (402) and raises the WRITE signal. Said 
Network Controller (403) also informs the Link Controller (401 ) by means of 
signal ISO whether said packet carries isochronous traffic. Once said data 
30 packet has been completely received by TX FIFO (402), said TX FIFO raises 
signal TXRDY to inform Link Controller (401) that it is now ready to output a 
data packet to USB Interface (63). 
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Once the Link Controller (401 ) determines that there are no conflicts for 
access to the USB Interface (63), said Link Controller (401) raises signal 
TXENB to indicate to TX FIFO (402) that it may now begin transmitting said data 
packet to said USB Interface (63). TX FIFO (402) then transmits said data 
5 packet to said USB Interface (63) one byte at a time by means of signal(s) 
TXBYTE. 

When all of the bytes within said data packet have been transmitted, TX 

FIFO (402) raises signal TXOVR to indicate to Link Controller (401) that the 

transmission is complete and other tasks related to USB Interface (63) can be 
10 scheduled. Link Controller (401 ) completes the handshake by lowering signal 

TXENB to prevent a further data packet from being transmitted without 

intervention by said Link controller. 

Figure 17 provides a sequence diagram showing a link layer packet 

input. In this drawing, control logic (420) Is implemented by Network Controller 
15 (403), control logic (421) is implemented by Link Controller (401), control logic 

(422) is implemented by RX FIFO (400) and control logic (423) is implemented 

by USB Interface (63). 

A link layer input sequence is started when RX FIFO (400) receives, by 

means of signal RXBYTE, the first byte of a new data packet from USB Interface 
20 (63). Thereupon, said RX FIFO indicates to Link Controller (401) by means of 

signal SOP that the start of a new packet has been detected. The remainder of 

the data packet is then received by RX FIFO (400) by means of additional 

RXBYTE signals. 

Once the complete data packet has been received by RX FIFO (400), 
25 Link Controller (401 ) is notified by means of End Of Packet signal EOP. 

RX FIFO (400) then transfers the complete packet to Network Controller (403) 
by means of signal READ. 
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Figure 18 provides an algorithm for implementing link control functions 
according to the invention of Figure 15. In the embodiment of Figure 15, the Link 
Controller functions of Figure 18 are implemented by a discrete Link Controller 
block (401). 

5 On initial power-up and after a reset, the system enters Idle state (470) 

where it waits for a signal to be received. 

If the received signal (471) is TXRDY, the system checks (472) whether 
the guard flag has been set. If said guard is set, the system returns to the Idle 
state (470), If said guard flag is not set, the system sets (473) said flag to 
10 indicate that the system is not ready to transmit another packet. The system 
then checks (474) the ISO signal to determine whether the packet to be sent 
represents an isochronous transfer. If said ISO signal is true, the guard timer is 
set (475) to 2 bit-times. If said ISO signal is false, the guard timer is set (476) to 
16 bit-times. The system then sets (477) signal TXENB to indicate that 
15 transmission of the packet to the USB Interface (63) can commence and moves 
to the Transmit state (478). 

When the complete packet has been transmitted to the USB Interface, 
the system receives (479) signal TXOVR, resets (480) signal TXENB to prevent 
premature transmission of another packet, starts (481) the guard timer with its 
20 previously set value, and returns to the Idle state (470). 

If the received signal (482) is Timer Expired, the system resets (483) the 
guard flag to indicate that another transmission can occur. The system returns 
to the idle state (470). 

If the received signal (484) is SOP, the system enters the Receive state 
25 (485) where it remains until it receives the EOP signal (486) indicating that a 
complete packet is now available in RX FIFO (400). The system returns to the 
Idle state (470). 

Having described specific embodiments of the present invention, it will be 
understood that modifications thereof may be suggested to those skilled in the 
30 art, and it is intended to cover all such modifications as fall within the scope of 
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the appended claims. Additionally, for clarity and unless otherwise stated, the 
word "comprise" and variations of the word such as "comprising" and 
"comprises", when used in the description and claims of the present 
specification, is not intended to exclude other additives, components, integers 
steps. 
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ABSTRACT 

The present invention provides a method and apparatus to be used to 
extend the range of a standard USB devices when utilizing asynchronous data 
streams. An extended range hub is provided which comprises a Local Expander 
(LEX) and a Remote Expander (REX) which can be separated by up to, for 
example 100 meters. The method and apparatus permits USB devices to be 
more conveniently located and used. 



